1. Field of the Invention
The present invention relates to a telecommunications network and a platform which controls the telecommunications network by managing call processing within the telecommunications network and handling other functions such as the assignment of resources, signalling and switching.
2. Discussion of Background Information
Over the years, telecommunications networks have vastly improved in their ability to enable network users to receive what is termed xe2x80x9cpersonalized services.xe2x80x9d These services are personalized in that they are oriented toward the user/subscriber instead of the network in general; that is, the user can decide which network service or services he or she wishes to subscribe to, as opposed to the user getting, and paying for, all services that the network provides.
One type of network that is particularly well suited for the provision of personalized services is the intelligent network. Intelligent networks centralize service-related intelligence in special nodes located in the telecommunications network. The intelligent network is well suited for telecommunications systems providing personalized services since it allows the setting up and management of network services that require sizable data and call handling resources.
An article by Sadaba (Telefonica de Espana) entitled xe2x80x9cPersonal Communications in the Intelligent Network,xe2x80x9d British Telecommunications Engineering, Vol. 9, August, 1990, pages 80-83, notes the importance of intelligent networks with respect to personalized services. The article generally describes (at pages 82-83) the concept of intelligent networks, and notes that intelligent networks treat all calls individually, dependent upon several parameters and variables. The article further explains that several entities are involved in the control of a call, and that switching functions are clearly separated from the control functions. The article states that separation of the switching functions from the control functions allows the resulting network to be more flexible in the way that it handles telecommunications functions, such as numbering, charging, routing, subscriber location, network management and service creation. Accordingly, intelligent networks have been deemed important in providing for flexibility in network management, service creation, and provisioning in telecommunications networks. Intelligent networks have been embodied in various forms, including well-known versions such as IN/1, IN/2 and IN/1+, as well as the advanced intelligent network (AIN) releases. A particular AIN architecture is described by Roger K. Berman and John H. Brewster in an article entitled xe2x80x9cPerspectives on the AIN Architecture,xe2x80x9d IEEE Communications magazine, February 1992, pages 27-32. In that article, a particular AIN release 1 architecture is described at pages 28 and 29. The physical systems and interfaces included in the AIN architecture are shown in FIG. 1 of the article.
The article further discloses, in an appendix at page 31, more detailed information about an AIN release 1 call model. The AIN release 1 call model is described as comprising two components, including a basic call model (BCM) and a connection view (CV). The BCM provides a generic model of current call processing for basic two-party calls and describes when in call processing AIN switch capabilities can be utilized. The CV describes how service logic of a stored program control can access the AIN switch capabilities to influence call processing and the switch. The CV provides a generic view of call processing resources in the AIN switch to the SCP/adjunct, which view is independent of the switch vendor implementation, representing the essential characteristics of call processing resources needed by service logic, and hides the critical details of technical complexities of the resources from the service logic.
While the specifics of the AIN release 1 architecture allow for a certain amount of flexibility in the use of different switches, e.g., by hiding the physical details and technical complexities of the resources from the service logic, the AIN architecture is limited in many respects. Particularly, there is some room for improvement in the ability of a network platform to provide a wide range of personalized services, change the resources used by the platform, quickly create and deliver services, and provide OAMandP capabilities.
3. Definitions
The following terms are defined in order to provide a better understanding of the present invention as described herein.
Aggregate resource capability:
A resource capability that represents more than one basic capability.
Alarm factors:
The input states associated with a managed object which caused the object""s summary state to take on its current value. If all problems listed in the alarm states are resolved, the managed object""s summary state will return to CLEAR.
Application layer:
The application layer comprises all classes whose objects generically participate in call processing, including, e.g., the leg, session, event manager, event handler and application components.
Application component:
A basic unit of service function. Services are built using application components.
Basic capability:
Fundamental units of equipment functionality. A basic capability cannot be decomposed into other capabilities. Some examples of basic capabilities could be playing tones, and recognizing DTMF digits.
Call processing stack:
A hierarchy of objects that interact with each other to implement call processing. From bottom to top for a given active call, the stack comprises one or more logical resources, one or more channels, one or more virtual terminals, one or more legs, a session, and at the top of the hierarchy, a set of event managers, event handlers and application components that are utilized to execute various service logic units (service program).
Call processing virtual machine:
The software environment within which the flexible platform services run, consisting of generic call components and application components.
Capability:
A capability is any function that a piece of equipment can perform. Some example capabilities are playing tones, making voice calls and playing announcements.
Channel:
An object in the call processing stack that manages a path resource and a set of logical resources (which may be empty) associated with that path resource. A channel may also keep track of basic capabilities and resource capabilities supported by the resources that it is managing.
Event handler:
An object that appears in the event manager of a session. Each event handler waits for a particular event to occur, where the event is of a certain type and has a particular reference channel and reference leg. If an event occurs with respect to reference channel and reference leg, the event handler starts execution of the specified service logic unit assigned to it.
Event manager:
An object in (or associated with) a session that contains event handlers for that session. It may be arranged as an array, indexed by event type, of event handler lists.
Generic call components:
Software objects, comprising, e.g., sessions, legs, VTs (virtual terminals), channels and VUs (virtual users), that are used to represent the dynamic states of calls, and other information including how many calls are involved, what resources are being used, and so on.
Input state:
The set of states which serve as the input to one or more functions used to calculate the output states of a managed object. These states are communicated to the objects via the state distributor.
Intermediate model domain:
Managed object representation of objects existing in the real-time domain (RTD) and logical groupings of those objects.
Leg:
The application layer object that represents a party to a call. The leg manages both information about a single party in a call and the VT (virtual terminal) object associated with that party""s call. The leg may also perform other functions.
Link layer:
The software in the platform host that manages the communications link which connects physical resources to the host. The link layer passes messages between physical resources and the logical resource objects with which they are associated.
Logical resource:
An object in the call processing stack that represents one or more resources, e.g. hardware, software, firmware, etc. The logical resource may perform functions such as translating commands from higher layers into bit streams understandable by the resources it represents. Other functions that a logical resource might perform include translating reports from the resources it represents into calls to reporting methods that are present in the higher layers of the software.
Managed object:
A collection of a set of input states, a set of output states, a set of functions which calculate the output states from the input states, and a set of functions which this collected entity can perform. This collection of information within the managed object may be used to represent either a physical or logical entity within the platform system.
Output states:
The set of states which provide a consolidated view of the information feeding into a managed object. The output state is defined by a function using one or more of the managed objects of the input state of the managed object as parameters. The input states are communicated to that particular managed object via a state distributor.
Path:
Any medium that supports the transfer of information from a user located on the network to the platform, from the platform to a user on the network, or from one user on the network to another user on the network. Some example paths could include a voice path, or a data path.
Path resources:
A logical resource object that represents a resource that supports a path.
Platform:
The control component of a communications system infrastructure which manages the communication processes and handles assignment of resources, and other functions such as signalling and switching.
Presentation domain:
Applications used to present the object in the intermediate model domain (IMD) to an external system (e.g., an application program within an OAMandP work station).
Real-time domain (RTD):
Those components of the platform which directly support call processing, e.g., resources, channels, virtual terminals, and so on, as well as OAMandP specific objects which interact in real time with the call control object that supports call processing.
Reference channel:
The channel with reference to which an event occurs. The reference channel is not necessarily the same as the channel which produced the event. For example, an internal offer connection event is produced by a channel on the incoming side of a call. However, its reference channel is an unspecified channel and some leg on the outgoing side of the call. If a session receives an event with a particular reference leg and a particular reference channel and it contains an event handler for that event, with the particular reference leg and particular reference channel, it starts executing that particular corresponding event handler. The reference channel for an event is contained in a virtual terminal (VT) associated with the reference leg for that same event.
Reference leg:
The leg with reference to which an event occurs. The leg is not necessarily the same as the leg which produced the event (which may be called the originating leg). For example, an internal offer connection event may be produced by a leg on the incoming side of a call. But its reference leg may be some leg on the outgoing side of a call. If a session receives an event with a particular reference leg and reference channel, and it contains an event handler that corresponds to that event, reference leg, and reference channel, it will start executing that event handler. The reference leg for an event is associated with a VT that contains the reference channel for the same event.
Resource capability:
A capability that represents one or more basic capabilities.
Resource layer:
In the context of a flexible network platform, as disclosed herein, the resource layer may comprise all logical resource, channel, and VT (virtual terminal) classes. With respect to a given call, the resource layer may comprise a set of objects within those classes that are participating in that active call.
Scratch variable:
Each event handler has a collection of scratch variables. If the event handler is considered to be a virtual machine for executing services, the scratch variable serves as its memory and register space. The scratch variables are used to perform calculations and store data that needs to be conveyed from one application component to another during execution of service logic.
Service logic unit (SLU):
The body of service logic that an event handler executes. A service logic unit may be simply called a service unit. A service may be composed of one or more (usually more) service logic units.
Sessions:
The software object to which all legs in a call attach themselves. A session transmits event reports from channels via legs to the event handler assigned to handle those events.
Singular resource capability:
A resource capability that represents only one basic capability.
State distributor:
A component of a platform OAMandP subsystem that provides a communication mechanism by which multiple processes may be concurrently informed of changes in the state of the platform.
State information client:
A process which initiates certain actions when notified by the state distributor of a change in the value of a specified state.
State information server:
A process which monitors or maintains a specific state and communicates information about that state via the state distributor.
Summary state:
A state used to describe the state of a managed object. The summary state may include terms such as CLEAR, MINOR, MAJOR, CRITICAL, INITIALIZING or UNKNOWN.
Universal information network (UIN):
A network that deals not only with voice-based personalized services, but handles services handling/using other types of media including audio and video, as well as text information.
Virtual synchrony:
A property of a distributed system under which each recipient of a set of events receives those events in the same order that would be produced if the event happened everywhere at the same time. A virtually synchronous system will not guarantee that distributed events occur at the same time, but only that they will be ordered (i.e., set into motion) at all recipients as if they had occurred synchronously.
Virtual terminal (VT):
An object in the call processing stack that manages a set of channel objects associated with a single user.
Virtual user (VU):
An entry in the database that stores persistent data about a subscriber to platform services. Such data may include, for example, the name, address and subscribed services of that user. Originating callers who have not subscribed to any originating services may be associated with a virtual user entry which corresponds to a default origination service.
In view of the above, the present invention, through one or more of its various aspects and/or embodiments, is thus presented to accomplish one or more objectives and advantages, such as those noted below.
It is an objective of the present invention to provide a universal information network platform that is flexible, and that can aid in the performance of several functions including: call processing and service execution; database maintenance; service creation; service and user data provisioning; OAMandP; and switching, routing and translation.
It is a further objective of the present invention to provide a network component that can provide a wide range of telecommunications services.
It is a further objective of the present invention to provide a universal information network platform that is flexible and a that can be easily expanded or modified to be able to provide different services.
It is yet a further objective of the present invention to minimize the amount of time it will take from definition to delivery of a particular service. Another objective of the present invention is to reduce the complexities of integrating services or service modifications into the network, so that less skill is needed to develop new services.
A further objective of the present invention is to reduce the amount of resources needed to provide a wide range of telecommunication services. In addition, the present invention strives to provide service application programs that can perform call processing in accordance with defined service logic, without having to handle hardware allocation and deallocation directly.
It is yet a further objective of the present invention to provide a mechanism for interfacing service control to other hardware and software resources, without limitations as to the resource type. Therefore, it is an objective to provide a system that will not have limitations on the ability to integrate different types of resources into the service providing platform. For example, there should be no limitation on the type of vendors or the type of technologies used in order to implement resources utilized by the service providing platform.
It is yet a further objective of the present invention to provide an OAMandP system that will work in connection with a flexible network platform, where the OAMandP system gathers and maintains information about the state of various entities within the flexible network platform, and makes that information easily accessible.
It is yet a further objective of the present invention to provide an OAMandP system that gathers and maintains information about the states of various entities within the call processing mechanism of a platform, without adversely affecting the platform""s ability to perform call processing. It is an objective to provide such an OAMandP state information gathering system which does not require the call processing system to take an active part in gathering and maintaining such state information.
It is yet a further objective of the present invention to provide a flexible managed object hierarchy which presents information in a certain standard way to OAMandP information clients (including information about what information is provided, where further information may be obtained, and what actions the clients may take with respect to that particular state information). Thus, it is an objective of the present invention to allow the introduction of new types of managed objects without requiring changes to the architecture or configuration of information clients that may call upon information from the managed objects.
A further objective of the present invention is to provide a flexible network platform which will allow new service provisioning and modification to be quickly and easily delivered. A further objective of the present invention is to provide such a flexible network platform which allows services to execute in an asynchronous environment, but to allow service logic to be programmed in a sequential fashion without the need to handle asynchronous events.
It is a further objective of the present invention to provide service logic that can be interpreted in a threaded fashion in order to allow services to be modified and added to extended data interfaces without the need to recompile or halt the system. A further objective of the present invention is to provide a threaded interpretative service logic mechanism which does not trade speed of execution for flexibility.
It is a further objective of the present invention to provide a call processing virtual machine which does not assume a call model or any template into which service logic must fit. It is an objective to provide a call processing virtual machine within which a platform will allow any piece of service logic to be associated with any particular event that would be seen by the platform.
It is a further objective of the present invention to separate service software from resource layer software, so that the service software need not know the particulars about the physical resources connected to the platform.
The present invention is directed to a flexible network platform, and to various subsystems that may be provided in connection with a flexible network platform. In accordance with one aspect of the invention, a telecommunications services network platform is provided for controlling the processing of calls in accordance with one of a plurality of defined services. The network platform may include a call processing system for performing call processing in accordance with defined service logic, and call processing resources connected to the call processing system.
The resources may include at least one media processor and a switching system for routing information among the at least one media processor and entities connected to the telecommunications network. The switching system is connected to a telecommunications network, to the call processing system, and to the resources.
The call processing system may be provided with session means for representing an active call with a session object, and means for forwarding external events associated with the active call to the session object. In addition, a mechanism may be provided for creating an initial call creation event handler object, which has a particular method, variables, and values for the variables. A further mechanism may be provided for registering the initial call creation event handler object with the session object. The initial call creation event handler object is associated with a particular event type, a party of an active call, and a communication path used by the party.
The session object receives the particular event and includes a mechanism for calling an event handler method within the initial call creation event handler object. The method of the initial call creation event handler object performs several functions in accordance with variables set forth in the initial call creation event handler object. The variables may include a service logic unit identifying variable, and the several functions may include commencing execution of a service logic unit.
A mechanism may also be provided for registering additional event handler objects in response to requests by application components being executed within a service logic unit. Each additional event handler object corresponds to a service logic unit.
In accordance with another aspect of the present invention, a resource managing system may be provided for assigning resources for use in performing call processing by a call processing system. A resource is assigned in response to a request made by the call processing system for a particular capability. The resource managing system includes a mechanism for receiving a request made by the call processing system for a specified capability. A plurality of logical resource objects are defined, each logical resource object comprising a mechanism for translating generic resource commands made by the call processing system into a form compatible with actual resources coupled to the call processing system. A further mechanism may be provided for correlating which logical resource object supports each capability within a set of capabilities that may be requested by the call processing system. In addition, a mechanism is provided for allocating a logical resource object that supports the specified capability.
The above-listed and other objectives, features and advantages of the present invention will be more fully set forth hereinafter.